[WIP] restructure hardware config #655

fmessmer · 2017-04-14T15:13:14Z

related to #437
includes #654 but will be rebased properly once that is merged...

trying to find a concept for this...this is rather a testing PR atm!

fmessmer · 2017-04-14T16:54:30Z

in 2f0866b I introduced launch files for each of our base modules (naming according to Verbautliste)...

As a first example, I then extracted the configuration for the laser scanners (sick_s300, sick_lms1xx) from the robot-specific configuration (i.e. cob_hardware_config/robots) and split it into component-specific yaml (i.e. driver settings) and module-specific settings (e.g. host/port, scan_interval).

I think, this is pretty much what we discussed...
Step by step we could now move more and more module-/components-specific configurations from the robot-specific cob_hardware_config/robots and create according module launch files and component yamls...

@ipa-nhg @ipa-fmw @ipa-mig @ipa-mdl FYI

fmessmer · 2017-04-17T17:01:33Z

I moved on a bit further...restructuring the actuators...I'm not sure whether arms sensorrings and grippers should actually be modules themselves....

Latest commit 7143c9c is roslaunch-dump-verified
Feedback wanted!

floweisshardt

looks good in general, although I need more explanation about the differences between component, module and bundle...

floweisshardt · 2017-04-18T13:03:14Z

cob_bringup/bundles/base_cob4.launch

 	<arg name="can_device" default="can0"/>
 	<arg name="pkg_hardware_config" default="$(find cob_hardware_config)"/>
 	<arg name="sim" default="false"/>

-	<arg name="driver_yaml" value="$(arg pkg_hardware_config)/robots/common/cob4_base_driver.yaml"/>
-	<arg name="controller_yaml" value="$(arg pkg_hardware_config)/robots/common/cob4_base_controller.yaml"/>
+	<arg name="driver_yaml" value="$(arg pkg_hardware_config)/modules/base/common/base_cob4_driver.yaml"/>


I'd prefer to keep cob4 prefix before base prefix. what's your rational to change this?

as we are grouping by module, I'd have the "module" as prefix...grouping the launch files, too

floweisshardt · 2017-04-18T13:04:59Z

cob_bringup/bundles/schunk_powercube_legacy.launch

@@ -1,23 +1,27 @@
 <?xml version="1.0"?>


do we still have supported robots using legacy version of schunk components? if not, we can get rid of this.

raw3-1 torso is using the legacy schunk_powercube_chain

floweisshardt · 2017-04-18T13:07:11Z

cob_bringup/robots/base_solo.launch

 	</include>

-	<include if="$(arg use_old_base_drive_chain)" file="$(find cob_bringup)/components/legacy_base.launch">
-		<arg name="robot" value="$(arg robot)"/>
+	<include if="$(arg use_old_base_drive_chain)" file="$(find cob_bringup)/bundles/base_legacy.launch">


do we still have supported robots with legacy version of base?

Afaik, the r@w's could be switched to the canopen version, but not the cob3-X Bruno just reactivated...

currently it's us not moving on here....the only robots using legacy base are raw3-1 and raw3-3 - raw3-5 could be used as a template..see #422

mgruhler · 2017-04-19T06:33:19Z

cob_hardware_config/components/sick_s300/sick_s300.yaml

 publish_frequency: 12
-scan_intervals: [[-2.0, 2.0]] #[rad] these intervals are included to the scan


I'm still not sure if it makes sense to have those parameters only "component-specific". The ones you pull out are definitely depending on the real instance of the sensor. The rest could, however, in theory be changed as well.

What I don't like too much is that we now have the parameters in two places. The yaml file here and the launch args in the respective modules. This probably makes sense for many nodes, but especially for this one, one could argue that if those cannot/should not be changed depending on the real instance, they could/should be hard-coded and not parameters at all.

I fully understand the idea behind this, but I think there are cases where it is difficult to decide what is depending on the real sensor and what on the sensor type...

It's not even just that, i.e. deciding whether it's "instance-general" (identical for all instances of the same component/module/robot) or "instance-specific" (possibly different for each instance of the same component/module/robot)...

...I had severe brain-knots when needing to decide whether to call s.th. an instance, a component, a module, a bundle....or simply keep it in robot...

Thus, so far, I don't see the real benefit of this restructuring myself...I know where we want to go, but I have no concept for it (yet)...
However, I think we should go for an approach where we combine/generalize things that are currently identical - even if at a future point we might introduce a new instance that requires different configuration....I think we should handle such case once it occurs - rather than already considering the most general, galactical configuration structure possible...it's all about making our life easier atm, i.e. now, i.e. with the requirements we currently have (not the ones we might have in the future - maybe)

If someone knows a good concept to do so, please provide input @ipa-nhg @ipa-mdl

Apart from that, I once heard about a "templatable" yaml approach (ros-industrial/universal_robot#144), but I never got an answer about how to use it...
Does someone know more about it?

mgruhler · 2017-04-19T06:35:05Z

cob_hardware_config/components/sick_lms1xx/sick_lms1xx.yaml

@@ -0,0 +1,3 @@
+angle_resolution: 0.25 #deg
+scan_frequency: 25 #hz
+set_config: false


Here, the same holds as for the s300 below. Those parameter might need to be changed depending on the instance of the sensor, not the component of "lms1xx" in general.

You can configure the scanner to have a resolution of 0.25 or 0.5 degrees (probably even some more). You could even have one of each on one single robot.

Do you see my point?

ipa-nhg · 2017-04-19T06:40:26Z

My idea was a little bit different, a module is for example the cob4-t7 and this module contains the torso axis, 3 pcs, light, 3 cameras..
And the robots/cob4-X should be a combination of modules, in case that we exchange the modules this combination could be auto-generated, in an ideal world only the urdf and the launch file... but this will be a next step...

fmessmer · 2017-04-20T11:46:46Z

@ipa-nhg
Do you want to propose your own concept yourself?
Should we do this in a (e.g. half-day) hackathon-style session? maybe next week?
(@ipa-fmw @ipa-mig feel free to join if you like...)

floweisshardt · 2017-04-20T13:10:10Z

yes, I'd like to join. let's plan on monday during our sprint planning session

fmessmer · 2017-05-06T13:16:24Z

closing (unmerged) due to #437 (comment)
I'll keep the branch though...

fmessmer added the waffle review label Apr 14, 2017

fmessmer force-pushed the restructure_hardware_config branch 2 times, most recently from dd47599 to 2f0866b Compare April 14, 2017 17:42

fmessmer force-pushed the restructure_hardware_config branch 2 times, most recently from d753027 to 7143c9c Compare April 17, 2017 19:54

floweisshardt reviewed Apr 18, 2017

View reviewed changes

fmessmer added 8 commits April 18, 2017 15:52

make laser scanner module-specific instead of robot-specific

68a574a

restructure scan_unifier

2eaf25c

restructure twist_mux

edc3324

restructure teleop

efe0225

group base

0284311

restructure bundles

8c2c8f8

restructure base module

b95ec08

restructure actuators

1835b81

fmessmer force-pushed the restructure_hardware_config branch from 7143c9c to 1835b81 Compare April 18, 2017 13:53

mgruhler reviewed Apr 19, 2017

View reviewed changes

fmessmer self-assigned this Apr 25, 2017

fmessmer closed this May 6, 2017

fmessmer removed the waffle review label May 6, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] restructure hardware config #655

[WIP] restructure hardware config #655

fmessmer commented Apr 14, 2017 •

edited

Loading

fmessmer commented Apr 14, 2017 •

edited

Loading

fmessmer commented Apr 17, 2017 •

edited

Loading

floweisshardt left a comment

floweisshardt Apr 18, 2017

fmessmer Apr 18, 2017

floweisshardt Apr 18, 2017

fmessmer Apr 18, 2017

floweisshardt Apr 18, 2017

mgruhler Apr 18, 2017

fmessmer Apr 18, 2017 •

edited

Loading

mgruhler Apr 19, 2017

fmessmer Apr 19, 2017

fmessmer Apr 19, 2017

mgruhler Apr 19, 2017

ipa-nhg commented Apr 19, 2017

fmessmer commented Apr 20, 2017

floweisshardt commented Apr 20, 2017

fmessmer commented May 6, 2017

		publish_frequency: 12
		scan_intervals: [[-2.0, 2.0]] #[rad] these intervals are included to the scan

[WIP] restructure hardware config #655

[WIP] restructure hardware config #655

Conversation

fmessmer commented Apr 14, 2017 • edited Loading

fmessmer commented Apr 14, 2017 • edited Loading

fmessmer commented Apr 17, 2017 • edited Loading

floweisshardt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fmessmer Apr 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ipa-nhg commented Apr 19, 2017

fmessmer commented Apr 20, 2017

floweisshardt commented Apr 20, 2017

fmessmer commented May 6, 2017

fmessmer commented Apr 14, 2017 •

edited

Loading

fmessmer commented Apr 14, 2017 •

edited

Loading

fmessmer commented Apr 17, 2017 •

edited

Loading

fmessmer Apr 18, 2017 •

edited

Loading